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Rcroarks/Arfiuments 

The amendments set forth herein are provided solely to clarify the invention as 
filed and set forth in the pending claims In order to comply with applicable statutes and 
regulations. The amendments are not intended to limit the invention or preclude the 
application of equivalents which Applicant may be entitled to under law. 

Status of the Applicatiftn 

Applicant respectfully requests reconsideration of the rejections and objections set forth 
in the OfFice Action mailed on 6/14/2007. 

Claims 1, 6, 9, 19, 25 and 26 were rejected under 35 ITSC 1 12, fir^t paragraph, as 

not complying with the enablement requirement. Claims 23, 25 and 26 were rejected 
under 35 USC 1 12 second paragraph as being indefinite. Claims 1 , 6, 9, 19, 21-23. 25 
and 26 were rejected under 35 USC 101 as being directed to non-^statiitoty subject matter. 

Cl^im rejections - 35 USC §1 12, first paragraph 

Response to section 7: Examiner^s rejection of independent claims U 19, and 23 under 
35 USC 1 12, first paragraph on the basis that the specification does not set forth how the 
performance metrics are to be determined is respectftilly traversed in part and overcome 
in part. Applicant traverses on the basis that, in fact, the specification contains a very 
detailed teaching of how the performance metrics are to be determined. 

As the specification teaches in paragraphs [0006], [0007], [0034] and elsewhere, the 
system is a computerized way to rate customer satisfaction vAth a vendor or supplier of 
goods or services. To demonstrate that the specification does, in fact contain teaching as 
to how the performance metrics are to be determined, consider an example where a user 
wishes to construct an automated pizza restaurant (supplier) rating system. 
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Here, the specification teaching is cited to show how cunstmct an automated system that 
can let one or more users determine which of the various local pizza restaurants are the 
most suitable suppliers for pizza, based upon past experience with these respective 
restaurants. The system is designed Lu allow it to be updated with the latest pi^za 
ordering experience, in order to give the most accurate results possible. 

To begin with, considci Clic situation where the user wishes to enter a newly opened plzzu 
restaurant into the system. How should the performance metrics for this new pizza 
restaurant be initially established? Here, specification paragraph [0028] teaches that the 
initial value for each performance metric can be an averaEe vaJue such as 3 "e,g. 3 out of 
5'\ This makes sense, since without any specific knowledge about the quality of a 
particular pizza restaurant; the most raeaningjful guess that can be made is that it is about 
average. So, following paragraph [0028], the user instructs the system to rate the new 
pizza restaurant "3" on every performance metric. The specification also shows this in 
specification table 1 ''part 1: Supplier rating matrix before feedback"'. 

Here, since the user is rating pizzas, the performance parameter most equivalent to 
"dimensional tolerance" is the restaurant's ability to actually deliver the correct type of 
pizza (correct pizza size and toppings) that the user ordered, and since the average pizza 
restaurant is expected to deliver pizza in less than an hour, the '^turnaround time" will be 
a different time scale, but otherwise the concept is similar to that illustrated m Table 1 . 

The user now decides to evaluate the new pizza restaurant by ordering pizza, but (in this 
example) unfortunately the user has a bad experience. The restaurant sends the wrong 
size and type of pizza (the user requested a large pepperoni pizza and got small anchovy 
pizza), the delivery time was 4 hours late, the pizza restaurant charged twice as much 
normal, and the service was poor because the delivery person was rude. How should the 
performance metrics fox this particular pizza restaurant be changed? Specification 
paragraph [0034] teaches that the user needs to quantijfy (rate) the performance of the 
supplier (the pizza restaurant) for this particular job, and enter this into the system. 
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PaTagraphs [0035] to [0017] show the math behind this piwcss, and this is also explained 
in detail in paragraphs [0052]-[0064], and Table 1 part 2 ''applying customer feedbacie' 
and Table 1 part 3 ''rating a supplier for a proposed job". 

Specifically the specification teaches the next steps in paragraph [00531 "the supplier has 
just completed a fob for the customer" (here the job was delivering the pizza). Following 
specification paragraph [0053], ihe user rates the supplier in terms Of speed, quality, cost 
and service on a scale of 0-5, where 0 is unacceptable, 1 is poor, 2 is below average, 3 is 
average, 4 is good, and 5 is perfect. Since the pizza restaurant was very slow, sent the 
wrong pizza, changed way too much, and the delivery person was rude, following the 
teaching of specification paragraph [0053], the user would Rive them an "actual 
performance vector'' of {0,0.0,0} : 0 for speed, 0 for quality, 0 for cost, and 0 for service. 

Following the teaching of specification paragraph [00561, the user would then 
mathematically update the supplier rating matrix, which in this example would be a 
mati ix composed of the results from a list of various local pizza restaurants, and how well 
the restaurants performed on various aspects of pizxa delivery, as shown by the math in 
paragraphs [0057-[6067]. 

One important policy question is; how much does the user want to alter a restaurant's 
overall rating based on just one good or bad delivery experience? Should the restaurant's 
overall rating be based on just their last job, i.e. "the restaurant is only as good as its last 
pizza delivery", or should the restaurant's overall history be taken into accoxmt as well, 
and the restaurant's rating then be slowly increased or decreased as the user accumulates 
additional experience over the cotirse of many pizza delivery jobs? 

Specification paragraph [0060] shows that this policy decision can be entered into the 
system's math in the form of the mSSL constant "h", where h=l makes the math give 
1 00% of the rating based only on the user rating of the most recent job experience. As 
the "h" value decreases, the system weights past user job ratings more and more, and h=0 
makes the math ignore all recent job experience. The specification goes so far as to 
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suggests that an appropriate value to use for h is: This is roughly equivalent to 

basing 80% of the restaurant's (or supplier's) overall rating on past experience, but 
changing this by about 20% based on the suppliers perfoni^ance (user rating) for the latest 
job. The specification (tabic 4) sliows huw negative performance can result in poorer 
ratings. 

So if h-1, the pizza rcaLaurant's present supplier rating would be ^'0" on all parameters 
Cthe restaurant is only as good as its last job, and the last job was rated as terrible"), if 
h=0, the restaurant's present supplier rating would still be "3" on all parameters (h=0 is 
equivaleul lo ignoring all recent experience). The intermediate h values, such as the 
h=0.2 value recommended by the specification, vAll in this example lower the pizza 
restaurant's parameters to less than 3 based on this one bad job. The exact number can be 
calculated according to the equations in specification paragraphs [0059J-[0068], 

Tliis system has many industrial and commercial uses, and the pizza example here has 
sixnply been used as a simple illustration. As far as additional uses go, specification 
paragraphs [0007], [0016], [0018], [0025], and figure lb teach that the sy5rf£m can be 
used here an automated computerized network system to allow users to keep a "web page 
on the internet, through a client/server system, over an Intranet, on an internet appliance 
and/or on aperson£il computer. The system may be used as part of a marketplace with 
numerous buyers and suppliers or for a single enterprise.,, " (specification paragraph 
[0007]). Thus in this example, the specitication is teaching the user how to produce a 
web based automated pizza restaurant recommendation and rating system, that can 
continually "leam" about pizza restaurant perfoitnance as restaurants chatige wath time. 

Thus applicant respectfully traverses the rejection on the basis that specification cle^u-ly 
teaches that performance metrics start at "3'' (average), and the specification also clearly 
teaches lowering the performance metrics to a smaller number if vendor performance 
clearly does not match vendor norms, and clearly teaches increasing performance metrics 
to a larger number if vendor performance clearly exceeds vendor norms, and gives 
detailed mathematical guidance as to how these numbers are to be adjusted. 
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Additionally, as will be discussed in more detail in response to the 35 USC 101 
rejections, applicant respectfully overcomes this 35 USC 1 12 first paragraph rejection by 
amending independent claims 1,19, and 23 to more specifically teach certain 
specification limitations that better enable the performance metric art taught by 
independent claims I, 19, and 23. 

Applicant respectfully traverses the rejection of dependent claims 6, 9, 21, 22, 25 and 26 
on the basis that these claims are dependent claims to claims 1, 19, and 23, and thus 
inherit the same limiiatiuns of these claims, including the new limitations and detailed 
specification teaching as to how the performance metrics are to be established. 

Claim rejections - 35 USC §112, second paragraph 

Response lu Kection.9: The rejection of claims 23, 25, and 2b under 35 USC 1 12, second 
paragraph has been respectfully overcome. Independent claim 23 has been amended per 
examiner's suggestion to recite that the interface modules perform the cited functions. 

Claims 25 and 26 depend upon claim 23, and this claim 23 amendment thus corrects the 
issues with claims 25 and 26 as well. 

Claim rejections - 35 USC §101 

Response to section 10: Examiner's rejection of independent claims K 19. and 23 under 
35 USC 1 01 on the basis that the claims are not concrete is respectfully traversed in part 
and overcome in part. Applicant's traversal to reiterate the same traversal discussed at 
length earlier in this response for the 35 USC 1 12 first paragraph rejection of claims 1 , 
19, and 23. That is, applicant again tmverses on the basis that the specification does, in 
fact teach concrete examples of how performance metrics are defined. 
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To overcome, applicant has amended independent claims 1, 19» and 23 to more clearly 
express the specification's concrete teaching in the form of additional claim limitations. 

One new limitation shows how the initial rating matrix is generated. It states that the 
initial supplier rating matrix is populated bv cither average supplier ratings or bv rating s 
dete r mi ned by prior knowledge of gaid Daal history of said Supplier perfomiance : 

This limitation fmds support in specification paragraphs [0027]-[002S], table 1 part 1, 
tabic 2, and specification paragraph [0053] and [0081]. 

A second new limitation shows how the performance vector and performance metrics 
w<=»rk: each pcrfoniiaiicc metric is based up on the supplier's performance metric relative 
to the average perform ance metric for other suppliers that perform said job. This is 
supported by specification paragraph [0053] . 

Support for the wherein said first filter constant has a value between 0 andj.; limitation 
can be found in specification paragraph [0060]. 

A few minor granmiatical corrections have also been made. 
New claims: 

New claim 27 is essentially present methods claim 1, further limited by the computerised 
meaxuds lt:aching contained in specification paragraphs [00U7J, [0018] and figure lb. 

New claim 28 finds support in specification paragraph [0007]. 

New claims 29 and 30 find support in specification paragraph [0025] and figure lb. 

New claim 31 finds support in specification paragraph [001 6]. 
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Applicant believes that all pending claims are allowable and rcspeclfully requests a 
Notice of Allowance for this application from the Examiner, Should the Examiner 
believe that a telephone conference would expedite the prosecution of this application; 
the undersigned can be reached at the telephone nmubcr set out below. 

The Commissioner is authorized to charge any additional or credit any over-payments 
that may apply to Deposit Account No. 50-242 1 . 



Respectfully submitted, 

Dkvid Stevens 
Registration No. 38,626 

Stevens Law Group 
99 North First Street 
San Jose, CA 95113 
Tel: 408-288-7588 
Fax: 408-288-7542 
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